-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[metal] MTLDevice is thread-safe #8168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk
Are you sure you want to change the base?
Conversation
| } | ||
|
|
||
| pub fn raw_device(&self) -> &Mutex<metal::Device> { | ||
| pub fn raw_device(&self) -> &metal::Device { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add an entry to CHANGELOG.md if we are going to merge this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this is thread-safe - you can already safely call MTLCopyAllDevices() and/or MTLCreateSystemDefaultDevice() from any thread, and access the same instances that way.
|
Alright, this would be good to have this, but there are CI issues. |
|
For the record, Apple has in Xcode 26 marked the following types as
|
|
Sorry for the late response. I expect to handle this under 2 weeks |
|
Friendly poke :) |
|
Sorry definitely on my mind but I didn't find the time yet |
Description
MTLDevicelook like is safe to access from different threads, this remove theMutexaround it. Feel free to close if it's actually not, the Apple documentation is very unclear about that and only notice about the thread safety of the command queueTesting
Tested manually on iOS.
Checklist
cargo fmt.Runtaplo format.cargo clippy --tests. If applicable, add:--target wasm32-unknown-unknowncargo xtask testto run tests.CHANGELOG.mdentry.